COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂13-Oct-79  0717	GRAND@MIT-AI 	sugestion for modification to top-level  
From: GRAND@MIT-AI
Date: 10/13/79 10:13:17
Subject: sugestion for modification to top-level

GRAND@MIT-AI 10/13/79 10:13:17 Re: sugestion for modification to top-level
To: (BUG LISP) at MIT-AI
	Change (setq + -) to (or (equal + '+) (setq + -))


∂13-Oct-79  0904	Robert W. Kerns <RWK at MIT-MC>    
Date: 13 October 1979 11:48-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: MACRAK at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 12 October 1979 19:03-EDT
    From: Stavros M. Macrakis <MACRAK at MIT-MC>
    To:   BUG-LISP

    I had ↑D on and ground a function.  I got
    ; new list segment added to make this a long line (defun foo (x)
    							 bar q...
    That is, the GC message totally screwed up the grind.  I don't see
    how to avoid this though, unless GC messages remember what charpos
    they started at and restore that position at the end of the line....

The obvious thing would be for the message-printer to do a fresh-line operation
before the message and a new-line after.  (A fresh-line operation is like ↑PA
or (CURSORPOS 'A), but generalized to arbitrary streams).  Probably not worth
fixing in MacLisp, which is a loser anyway...

∂13-Oct-79  0910	Robert W. Kerns <RWK at MIT-MC>    
Date: 13 October 1979 12:09-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: ALAN at MIT-AI
cc: BUG-LISP at MIT-MC

    Date: 10/11/79 01:30:59
    From: ALAN at MIT-AI
    To:   (BUG LISP) at MIT-AI

    It looks to me like lisp will only ask for jcl when both the 
    OPTCMD and OPTBRK bits are set in .OPTION .  This makes it hard to
    pass jcl to an inferior lisp, because you have to handle all .BREAKS .
    It seems to me that if you do a (status jcl) and OPTCMD is set,
    then that is enough to justify interrupting your inferior.
Indeed.  The test should be for existance of a superior plus %OPCMD.

∂13-Oct-79  1620	ALAN at MIT-MC (Alan Bawden)  
Date: 13 OCT 1979 1920-EDT
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG QC) at MIT-MC

flags on the command line seem broken:

←alan;myfile > (t)
INCORRECT SYNTAX mumbel mumbel...


∂14-Oct-79  0153	GSB@MIT-ML
From: GSB@MIT-ML
Date: 10/14/79 04:51:45

GSB@MIT-ML 10/14/79 04:51:45
To: (BUG COMPLR) at MIT-ML
(declare (*lexpr foo)
	 (flonum (foo notype flonum fixnum fixnum fixnum fixnum)))

(defun bar (a) (foo a 0.0 1 2 3 4.0))

gives no complaints to the effect that 4.0 is not a fixnum.


∂16-Oct-79  0924	GLS@MIT-AI 	GRAND's suggestion
From: GLS@MIT-AI
Date: 10/16/79 12:20:55
Subject: GRAND's suggestion

GLS@MIT-AI 10/16/79 12:20:55 Re: GRAND's suggestion
To: (BUG LISP) at MIT-AI
CC: GRAND at MIT-AI
Maybe he really wanted to change (SETQ + -) to (OR (EQUAL - '+) (SETQ + -)) ?


∂16-Oct-79  2103	GRAND@MIT-AI   
From: GRAND@MIT-AI
Date: 10/16/79 22:39:58

GRAND@MIT-AI 10/16/79 22:39:58
To: GLS at MIT-AI
CC: (BUG LISP) at MIT-AI
	Isn't change (setq + -) to (or (equal - '+) (setq - '+))
what I said?

∂16-Oct-79  2204	GJC at MIT-MC (George J. Carrette) 
Date: 17 OCT 1979 0102-EDT
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

Rub-out processing inside ones own read macros
works sometimes but not all the time.
You know this of course, when a usual
lisp atom boundary is reached then you cannot rub out
after that (in time or space). If a boundary has not
been reached the rub-outs work as usual. If rub-outs
never worked in user read-macros (unless the user handles
them specificaly) then this would be o.k. But working
for some cases but not others is not soo good. Is
there a way to fix this? Can I turn off all rub-out
processing  (when inside the macro) and handle it myself?
Can it be made to work like on the lisp machine?

∂17-Oct-79  0237	Alan Bawden <ALAN at MIT-AI>  
Date: 17 October 1979 05:33-EDT
From: Alan Bawden <ALAN at MIT-AI>
To: GJC at MIT-MC
cc: BUG-LISP at MIT-AI, KMP at MIT-MC

Rubout processing on the LispMachine works at all times, even
in the middle of the wierdest reader macro.  This is because
a read is actually in process as you are typing, when you
type the rubout character a throw is done out of the reader
and it is re-invoked on whatever input is left as soon as you 
stop typing rubouts.  This has the wierd side effect that
syntax errors sometimes cause an error before you are even
finished typing the form.  GSB has a frob that does someting
like this in MacLisp, but for various reasons that he will
be happy to flame about, it cannot actually work in a working
MacLisp environment.

∂17-Oct-79  0332	ALAN at MIT-MC (Alan Bawden) 	damn 
Date: 17 OCT 1979 0632-EDT
From: ALAN at MIT-MC (Alan Bawden)
Subject: damn
To: (BUG QC) at MIT-MC

why doesn't it work to specify flags anymore?

←foobar (t)
INCORRECT COMMAND SYNTAX - MAKLAP

First of it seems crazy that the error message says "- MAKLAP"
but I suppose we have all gotten used to that bit of obscurity
by now...  ("what the hell is MAKLAP?  I thought I was running
something called complr or something like that...")

Secondly how the hell am I supposed to set these flags now anyway!?
I like setting the "t" flag (although naturally I have no idea
why the letter "t" was singled out for this purpose), and it
makes me nervous and irritable when I can't see which of my
beautiful functions the compiler is chewing up now.

∂17-Oct-79  0336	JONL at MIT-MC (Jon L White)  
Date: 17 OCT 1979 0637-EDT
From: JONL at MIT-MC (Jon L White)
To: ALAN at MIT-MC
CC: (BUG QC) at MIT-MC

    Date: 17 OCT 1979 0632-EDT
    From: ALAN at MIT-MC (Alan Bawden)
    Subject: damn
    To: (BUG QC) at MIT-MC
    why doesn't it work to specify flags anymore?
    ←foobar (t)
    INCORRECT COMMAND SYNTAX - MAKLAP
Failure of switch parser to recognize lower case.  
Will be fixed within the hour.

∂17-Oct-79  0643	JONL at MIT-MC (Jon L White)  
Date: 17 OCT 1979 0942-EDT
From: JONL at MIT-MC (Jon L White)
To: grand at MIT-AI
CC: GLS at MIT-MC, (BUG LISP) at MIT-MC

    GRAND@MIT-AI 10/16/79 22:39:58
    To: GLS at MIT-AI
    CC: (BUG LISP) at MIT-AI
	    Isn't change (setq + -) to (or (equal - '+) (setq - '+))
    what I said?
No, you had 
		  Change (setq + -) to (or (equal + '+) (setq + -))
I presume that the effect you want is: if you type a "+" at the
top-level loop, you don't want the next	value of + to be "+".
Quux's rewriting of this as
		  change (SETQ + -) to (OR (EQUAL - '+) (SETQ + -)) 
would accomplish this (more or less at TLEVAL).

∂18-Oct-79  0732	GLS@MIT-AI
From: GLS@MIT-AI
Date: 10/18/79 10:27:53

GLS@MIT-AI 10/18/79 10:27:53
To: GRAND at MIT-AI
CC: GLS at MIT-AI, (BUG LISP) at MIT-AI
    GRAND@MIT-AI 10/16/79 22:39:58
    	Isn't change (setq + -) to (or (equal - '+) (setq - '+))
    what I said?

No, you said (or (equal + '+) (setq - +)) [and in the above,
the last + should not be quoted, of course].


∂18-Oct-79  1139	GJC at MIT-MC (George J. Carrette) 
Date: 18 OCT 1979 1436-EDT
From: GJC at MIT-MC (George J. Carrette)
To: GSB at MIT-ML
CC: (BUG LISP) at MIT-MC, GJC at MIT-MC

Well, I'll try some of your suggestions out. Its not like its
very vital to have things read from the TTY in the correct way
in user read macros because I want to use them mainly to make code
look prettier in files. If there was a standard macro shell
that acted like | acts then that would be all I would need.
I want to have {cruft...n} read in as if it was 
(some-atom-crunching-macro |cruft...n|) then one could do explode or
whatever.  (SSTATUS STRING-LIKE-MACRO BALANCE { } 'some-atom-cruncher)
Macros wich call READ seem to win always, ones that call TYI loose,
and from your description its because of maclisps own tty pre-scanner,
sounds like its easier to add a fix to the system that will cover almost
all cases. Could the code for | be addapted slightly to cover this?
Is balancing harder then delimiting?

∂18-Oct-79  1143	JONL at MIT-MC (Jon L White) 	''rubbing out'' string-like tokens in maclisp
Date: 18 OCT 1979 1440-EDT
From: JONL at MIT-MC (Jon L White)
Subject: "rubbing out" string-like tokens in maclisp
To: GJC at MIT-MC
CC: GSB at MIT-MC, KMP at MIT-MC, ALAN at MIT-MC, (BUG LISP) at MIT-MC

THe soon-to-be-released maclisp, version 1873, has a 
function for " as a read-macro, but it is not initially
set up (so that losers who are using it in an alphabetic
way can't complain).  If you do the SETSYNTAX to make
it a macro, it will "rubout" the same way as | - there
is a new variable holding an a-list for characters which
delineate string-like tokens.  To get a preview, see
MC:LISP;NEW RECENT

∂18-Oct-79  2028	Glenn S. Burke <GSB at MIT-ML> 	format of (status features) 
Date: 18 October 1979 21:34-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: format of (status features)
To: BUG-LISP at MIT-ML, BUG-LISPM at MIT-ML
cc: BSG at MIT-ML

The maclisp manual claims that (car (last (status features))) is
the implementation name.  I have also been under the impression
that (cadr (reverse (status features))) was itself significant, ie
the "machine identifier" or somesuch (eg "ML"), but i don't have
an old manual handy to see if it actually claims this.  I see however
that multics maclisp now has "Maclisp" as the last element, and the
lisp machine uses neither of those last elements.  It would be kind
of nice if these items could be found by some means other than 
enumeration.
   ITS people:  Can't there be some hack so that the machine name
will be correct if a dumped lisp is transported?  Like making the last
two cons cells pure, so that SHAREP will make it be correct?


∂19-Oct-79  0056	KMP at MIT-MC (Kent M. Pitman) 	INCLUDEF
Date: 19 OCT 1979 0356-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: INCLUDEF
To: (BUG LISP) at MIT-MC, CWH at MIT-MC, RWK at MIT-MC, GLS at MIT-MC
CC: KMP at MIT-MC

RWK says it hasn't been officially released, so I'll make one last naming
plea ...  I don't think the subr version of INCLUDE ought to be called
INCLUDEF. There are several families of functions in MacLISP which deal
with files. They include (no pun intended) ...

  Family 1 - File system manipulators (fully external operations)

    PROBEF, RENAMEF, LINKF (non-existent, but hopefully to come soon?),
    DELETEF, ...

  Family 2 - Environment loaders (unit i/o)

    INCLUDE, LOAD, FASLOAD

  Family 3 - General I/O 

    UREAD, UWRITE, CLOSE, OPEN, ...

The first category all end in F. None of the others do. To
create a function INCLUDEF would violate this rule. The transformation 
of INCLUDE into a subr is more akin to the creation of the group:
((BREAK . *BREAK) (THROW . *THROW) (CATCH . *CATCH)).

INCLUDEF is an ugly name. I still vote for changing this to *INCLUDE.

-kmp

∂19-Oct-79  0334	RWK at MIT-MC (Robert W. Kerns)    
Date: 19 OCT 1979 0634-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

the LISP software device should be defined on ITS!  Say you have
(LOAD '|LISP:FOO BAR|), it would be nice if this would work as well
as (LOAD '((LISP) FOO BAR)), which happens to work merely because it's
ambiguous and gives you the LISP directory.

∂19-Oct-79  0339	RWK at MIT-MC (Robert W. Kerns) 	Foobar, '' broken
Date: 19 OCT 1979 0640-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: Foobar, " broken
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

"foo

"
==>|foo|

This is wrong, incompatible with every " macro I've ever seen.

∂19-Oct-79  0427	Scott at SRI-KL (Scott Kramer) 	faslp loss on twenex   
Date: 19 Oct 1979 0425-PDT
From: Scott at SRI-KL (Scott Kramer)
Subject: faslp loss on twenex
To:   bug-lisp at MC

This returns the proper value...and more.

(faslp '|qtrace.fasl|)
T 
;FXPDL OUT OF PHASE (SYSTEM ERROR)

;BKPT *RSET-TRAP

(faslp '|qtrace.lsp|)
NIL 
;FXPDL OUT OF PHASE (SYSTEM ERROR)

;BKPT *RSET-TRAP
-------

∂20-Oct-79  0504	JONL at MIT-MC (Jon L White)  
Date: 20 OCT 1979 0801-EDT
From: JONL at MIT-MC (Jon L White)
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, KMP at MIT-MC

    Date: 19 OCT 1979 0640-EDT
    From: RWK at MIT-MC (Robert W. Kerns)
    "foo
    
    "
    ==>|foo|
    This is wrong, incompatible with every " macro I've ever seen.
Not really - a decision long ago was that for maclisp, <carriage-return>
would be invisible unless slashed.  Try typing |AB<cr><cr>|  and see
what you get!  One argument is that maclisp's convention is contrary
to some other systems, but at least it is internally consistent.

∂20-Oct-79  0651	JONL at MIT-MC (Jon L White) 	FASLP loses on twenex    
Date: 20 OCT 1979 0949-EDT
From: JONL at MIT-MC (Jon L White)
Subject: FASLP loses on twenex
To: SCOTT at SRI-KL
CC: (BUG LISP) at MIT-MC

Gllaaag.  Found, and corrected in the source.  Will reassemble
within a day or so (other bugs being corrected too).  Tnx superly
for finding this one.

∂20-Oct-79  0952	JONL at MIT-MC (Jon L White)  
Date: 20 OCT 1979 1246-EDT
From: JONL at MIT-MC (Jon L White)
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, BSG at MIT-MC

    Date: 18 October 1979 21:34-EDT
    From: Glenn S. Burke <GSB at MIT-ML>
    Subject: format of (status features)

    The maclisp manual claims that (car (last (status features))) is
    the implementation name.  
Actually, it was meant to mean "name of operating system type", such
as TOPS-10, TOPS-20, TENEX, ITS, MULTICS . . .
			      I have also been under the impression
    that (cadr (reverse (status features))) was itself significant, ie
    the "machine identifier" or somesuch (eg "ML"), but i don't have
    an old manual handy to see if it actually claims this.  
This is not really a "feature" - it was used in the days when the
various ITS machines had to have different assemblies of LISP.  But
now, the same code is used on all three systems (yes, Virginia, we
don't make use of the fact that the KL10 has . . .)
							    I see however
    that multics maclisp now has "Maclisp" as the last element, and the
    lisp machine uses neither of those last elements.  It would be kind
    of nice if these items could be found by some means other than 
    enumeration.
This might seem a bug, if we would expect the last element to be the
supporting operating system name.

∂20-Oct-79  2135	KMP at MIT-MC (Kent M. Pitman)
Date: 21 OCT 1979 0033-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG QN) at MIT-MC

(DEFUN BUG (X) (BUG1 X X X))
(DEFUN BUG1 (X Y Z)
       (PRINT (LIST (MAKNAM X) (MAKNAM Y) (MAKNAM Z)) TYO))

Compile this and then do (BUG '(49.)) ... It prints out (/1 NIL ||) ...
I suspect this means MAKNAM is being allowed to clobber its arg in some
obscure way ...? Note the lossage doesn't occur for a similar function 
to BUG1 with only 2 args...

∂21-Oct-79  0800	JLK at MIT-MC (John L. Kulp)  
Date: 21 OCT 1979 1058-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

For what its worth, I like RWK's suggestion about the syntax of CR.

∂21-Oct-79  1021	APW@MIT-AI 	Effect of CR in symbols
From: APW@MIT-AI
Date: 10/21/79 13:01:03
Subject: Effect of CR in symbols

APW@MIT-AI 10/21/79 13:01:03 Re: Effect of CR in symbols
To: (BUG LISP) at MIT-AI

A good idea.

∂21-Oct-79  1023	DHD@MIT-AI 	crs in atoms 
From: DHD@MIT-AI
Date: 10/21/79 13:19:52
Subject: crs in atoms

DHD@MIT-AI 10/21/79 13:19:52 Re: crs in atoms
To: (BUG LISP) at MIT-AI
Why not make CR a force feed character, as in lispm?  This seems to be a major
problem with new maclisp users as well.  I definatly (sic) support the change.

∂21-Oct-79  1133	EB@MIT-AI 
From: EB@MIT-AI
Date: 10/21/79 14:29:58

EB@MIT-AI 10/21/79 14:29:58
To: (BUG LISP) at MIT-AI
I am in favor of the CR change.

Also, a question:  Is there now, or does there exist somewhere code to get,
or is it possible to have, a control character that erases to beginning
of line like Ctrl U does for most things on Tosp-20?
I realize that this would require some kind of line-buffering, but it
is terrible to have ↑G and ↑X be the only alternatives to lotsa rubouts.

Or failing that, is there a character (or could there be) to abort the
current read and do it over?  I understand there would be possible problems
with read-macros, but is any solution possible?



∂21-Oct-79  1257	Scott.Fahlman at CMU-10A 	Proposed CR change.
Date: Sunday, 21 October 1979 1551-EDT
From: Scott.Fahlman at CMU-10A
Subject: Proposed CR change.
To:   bug-lisp @ mit-mc
Message-ID: <21Oct79 155157 SF50@CMU-10A>


I like the proposed change to the default status of CR.  As a minor datum,
note that the default at CMU is to set CR as a break character (we also
use linemode input, mostly) so the change would not screw anyone here.
-- Scott

∂21-Oct-79  1308	SJOBRG@MIT-AI 	Effect of CR in symbols  
From: SJOBRG@MIT-AI
Date: 10/21/79 15:49:17
Subject: Effect of CR in symbols

SJOBRG@MIT-AI 10/21/79 15:49:17 Re: Effect of CR in symbols
To: (BUG LISP) at MIT-AI
I think <cr> should be a break character identical to space.
Does the proposed change mean just that, or something else?


∂21-Oct-79  1324	KMP at MIT-MC (Kent M. Pitman) 	Changing <CR> syntax   
Date: 21 OCT 1979 1620-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Changing <CR> syntax
To: (BUG LISP) at MIT-MC

I think I've expressed my favor of <CR> not being ignored in atoms any more,
but just for the record I thought I'd say it.

Does this mean that <atom><CR> would be like <atom><space>? ...  I think
that would be nice too... Confuse a lot less people who wonder why <atom><CR>
does nothing...

∂21-Oct-79  1335	HIC at MIT-MC (Howard I. Cannon) 	Effect of CR in symbols   
Date: 21 OCT 1979 1631-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Effect of CR in symbols
To: (BUG LISP) at MIT-MC

The current way CR's is handled is totally wrong.  Treating them basically
like space for symbols, and correctly in strings, is of course the right 
thing.

∂21-Oct-79  1413	ALAN@MIT-AI    
From: ALAN@MIT-AI
Date: 10/21/79 17:08:23

ALAN@MIT-AI 10/21/79 17:08:23
To: (BUG LISP) at MIT-AI
	Yes, Yes, Yes.  <cr> should be treated just as any other
whitespace character.  This has the effect that typing FOO<cr> at
toplevel will read the symbol FOO, which is what I gather people mean
when they talk about a force-feed character.
	The only objection I can see to correcting the syntax of <cr>
is that the printer will have to be fixed to not output a <cr> in
the middle of a symbol.  This cannot be too much of a screw since I 
have never, never actually seen the printer do this. (The LispMachine
printer doesn't output any <cr>s at all, and no one seems to mind.)

∂21-Oct-79  1608	RJF at MIT-MC (Richard J. Fateman) 
Date: 21 OCT 1979 1904-EDT
From: RJF at MIT-MC (Richard J. Fateman)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC, JPG at MIT-MC

IGNORING THE CR'S IN MACSYMA HAS THE EFFECT OF MAKING
FOR I:1 THRU 10 DO
PRINT(I);   BE A SYNTAX ERROR : DOPRINT IS NOT AN INFIX OPERATOR...
I THINK THIS IS A LOSS.  I THINK IT IS A LOSS IN LISP TOO, BUT THERE  MIGHT
BE REASONS FOR IT THAT I DO NOT KNOW ABOUT.  

∂21-Oct-79  1633	GJC at MIT-MC (George J. Carrette) 	CR  
Date: 21 OCT 1979 1926-EDT
From: GJC at MIT-MC (George J. Carrette)
Subject: CR
To: (BUG LISP) at MIT-MC

Uhm, the only changes it would make in my code is it would add extra CR's to
stuff inside |...|  The example is this:

(DOCUMENT-MACRO DOC1 '|
text......./
kdkdkjfjdk/
|

)
That is, I use the first hidden CR to make it easier to line up the document
text. But slashing all the CR's I want is also a pain. So I'd rather
have the extra CR ...


∂21-Oct-79  1853	GRAND@MIT-AI   
From: GRAND@MIT-AI
Date: 10/21/79 21:50:20

GRAND@MIT-AI 10/21/79 21:50:20
To: (BUG LISP) at MIT-AI
	Treating CR as a delimiter is just fine with me. I find
it to be a lot more natural to type that way. I currently have
the appropriate setsyntax in my init file to effect this.


∂21-Oct-79  2119	GJC at MIT-MC (George J. Carrette) 
Date: 22 OCT 1979 0016-EDT
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

WHATS AN SFA ?

∂22-Oct-79  0033	JPG at MIT-MC (Jeffrey P. Golden)  
Date: 22 OCT 1979 0331-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: RJF at MIT-MC, RWK at MIT-MC, JPG at MIT-MC

I am in favor of the proposed CR change.  However, it would 
certainly cause some trouble to MACSYMA if things were changed.  
(1) MACSYMA SAVE files are written to by using PRINT and CRs are generated 
by default in LISP when very long atoms (e.g. numbers) are printed.
I do not relish having to mend user's SAVE files to support this change.
Perhaps if any change here were switchable at least for some reasonable 
period of time while LISP stopped behaving in TERPRI NIL mode wrt 
printing very long atoms, things would be ok.
(2) A similar problem occurs on the user input end.  People would have 
to train themselves to overflow lines without typing CR when inputting 
long atoms.  I suppose this is not too much to ask.
(3) When I used to use ML's LPT, it used to overprint horribly when 
outputting atoms > its linel in length.  (I.e. when no newlines were used.)
Is it really the case that there are no similar lossages today, that if 
one tries to print out a very long atom that one will win no matter what 
the output device is, i.e. no obliterating overprinting will occur?

∂22-Oct-79  0056	JPG at MIT-MC (Jeffrey P. Golden)  
Date: 22 OCT 1979 0353-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: RJF at MIT-MC, RWK at MIT-MC, JPG at MIT-MC

One more thing:
(4) I guess if this change were to go through, there should be some 
way to specify "continuation" for very long atoms so that one could 
type "continuation"<cr><more junk> and have the <cr> ignored, so 
that one would not be forced to run near or over linel in order to 
input a very long atom.  This is almost necessary when using devices 
for later printout which have losing or blurred columns, etc.

∂22-Oct-79  0523	RLB at MIT-MC (Richard L. Bryan) 	CR in symbols and strings 
Date: 22 OCT 1979 0820-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: CR in symbols and strings
To: (BUG LISP) at MIT-MC

I've been waiting for that for years.  However, there's always the issue of
compatibility with files written by older MacLISPs.  What happens if a
symbol with FLATSIZE > linel is written?  MacLISP currently offers no 
line continuation character sequence, and either one would be needed, or
else we'd have to decide that it would be ok to write past linel.

∂22-Oct-79  0625	LH@MIT-ML 
From: LH@MIT-ML
Date: 10/22/79 09:23:29

LH@MIT-ML 10/22/79 09:23:29
To: (BUG LISP) at MIT-ML
Yes, by all means have CR act like a space.


∂22-Oct-79  0839	RBRN@MIT-AI 	CR in LISP  
From: RBRN@MIT-AI
Date: 10/22/79 11:33:26
Subject: CR in LISP

RBRN@MIT-AI 10/22/79 11:33:26 Re: CR in LISP
To: (BUG LISP) at MIT-AI, rwk at MIT-MC
Although there probably are not many programs that depend on CR being ignored, there are
(or at least historically were) several programs that groveled over LISP code,
and introduced CRs where none were before. For this
reason the syntax of CR should be left alone.
	Besides, what would be the purpose of such a change? 
	Anyway, for your own use you could probably just modify the syntax via your
own LISP init file.


∂22-Oct-79  1002	REM at MIT-MC (Robert Elton Maas) 	Changing CR in LISP, reply/opinion 
Date: 22 OCT 1979 1257-EDT
From: REM at MIT-MC (Robert Elton Maas)
Subject: Changing CR in LISP, reply/opinion
To: (BUG LISP) at MIT-MC

I presume the original reason for CR being ignored was that data written
out to a file with finite linelength shorter than the longest atom pname
or numeric value could be read back in without hassle even if the data
had been broken to make it fit.  How to you propose to handle this if the
change is made to break atoms across crlf?  (I have some programs
currently that generate large BIGNUMs and write them to files.  I don't
know if they are broken across crlf, since this is masked by TCTYP width
when I try to type it out, unless I look carefully and distinguish 72
from 78 characters.)  I have always been bothered by crlf being ignored
when I type in stuff, but have learned to live with it.  Living with
the "standard" way instead would be interesting...

∂22-Oct-79  1108	ARCHY at MIT-MC (William M. York, Jr.) 	Effect of CR in symbols  
Date: 22 OCT 1979 1405-EDT
From: ARCHY at MIT-MC (William M. York, Jr.)
Subject: Effect of CR in symbols
To: (BUG LISP) at MIT-MC

CR should NOT be ignored.
FOO
BAR
should be two symbols, FOO and BAR.

∂22-Oct-79  2014	GLS@MIT-AI 	Effect of CR in symbols
From: GLS@MIT-AI
Date: 10/22/79 21:38:53
Subject: Effect of CR in symbols

GLS@MIT-AI 10/22/79 21:38:53 Re: Effect of CR in symbols
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-AI, GLS at MIT-AI
If you make CR significant in delimiting atoms then it is imperative
that both PRIN1 and GRINDEF never ever ever break symbols across lines
(for PRIN1 it would suffice to make TERPRI have the other value (I can
never remember which is which) as the initial default).  Otherwise one
might write out code or data and then re-read it incorrectly.

Some languages have an "un-slash" character which can be used to un-escape
a carriage return or tab or whatever.  Suppose "\" to be such a character;
then writing
		|Foobar\<cr>
\	\	 this really bites the<cr>
\	\	 BAG!|
would be the same as writing |Foobar this really bites the<cr>
BAG!|.  I think Multics has such a character, for example.  This
is so that one can split things across lines for readability.


∂22-Oct-79  2111	BAK@MIT-AI 	Effect of CR in symbols
From: BAK@MIT-AI
Date: 10/23/79 00:08:28
Subject: Effect of CR in symbols

BAK@MIT-AI 10/23/79 00:08:28 Re: Effect of CR in symbols
To: (BUG LISP) at MIT-AI
I am 100% for RWK's suggestion, and I wonder why this wasn't changed years
ago.  The only utility for the present lossage that I can think of is on
operating systems that do not support automatic wrap around when typing
beyond the screen limit (as ITS does).  This would be the only way to enter
symbols whose size is greater than the linel minus current position.  The
present scheme seems to help nobody and has 2 noticeable disadvantages.  
(1) What you see isn't what you get inside vertical bar'd symbols.  This is
particularly annoying because CRs don't print.  Slashified CRs look just
like slashes hanging in midair (which could be quoting a space for all you know).
(2) Normal conventions in virtually every other parser treat CR as a
delimeter for tokens.  Natural language text follows similar conventions.
This causes confusion, particularly with beginners.

∂22-Oct-79  2157	KMP at MIT-MC (Kent M. Pitman) 	Last minute paranoia about ignoring <CR>'s 
Date: 23 OCT 1979 0054-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Sent-by: TURNIP at MIT-MC
Subject: Last minute paranoia about ignoring <CR>'s
To: (BUG LISP) at MIT-MC

Some points to consider ... 

(1) JPG claims there may be a large number of Macsyma save files with bignums
    broken across lines... 
(2) As I recall, RLB mentioned something to me a long time ago about 
    compatibility on other sites where there is a maximum record-length 
    and records are delimited by <CR>'s ... this might mean it is impossible
    for a system to store lines past a certain length for us. Probably
    end-of-records could be special cased in some way so that the <CR> could
    be meaningful in all other places -- eg, <CR>'s that occur at that boundary
    might be ignored? a double-<CR> at that point might be needed for intended
    single <CR> there ... dunno.

I'm still in favor of flushing the current convention, but let's make sure
nothing much will break first ...

∂22-Oct-79  2159	KMP at MIT-MC (Kent M. Pitman) 	<CR>'s  
Date: 23 OCT 1979 0056-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Sent-by: TURNIP at MIT-MC
Subject: <CR>'s
To: (BUG LISP) at MIT-MC

... to my last note I should add that since no one has saved strings so
far there is no reason strings shouldn't instantly obey the winning
new convention (of making <CR> significant).

Also, I wonder if PRIN1/PRINT should know to print 'strings' specially with
"..." around them .......... probably not ...... just a thought, tho'.
-kmp

∂22-Oct-79  2304	DLW@MIT-AI
From: DLW@MIT-AI
Date: 10/23/79 02:01:29

DLW@MIT-AI 10/23/79 02:01:29
To: (BUG LISP) at MIT-AI
The change to have CRs break symbols is long overdue.  By all
means, put it in.  As I belive the printer has been fixed to allow
the operating system do the line-wraparound rather than inserting
the spurious CRLFs itself, which was the only reason for the
reader peculiarity anyway, I greatly doubt the number of bugs caused
will be > 1% of the number of bugs averted.


∂23-Oct-79  0903	RIVEST@MIT-ML  
From: RIVEST@MIT-ML
Date: 10/23/79 12:01:16

RIVEST@MIT-ML 10/23/79 12:01:16
To: (BUG LISP) at MIT-ML
I'm in favor of CR being treated as a blank!!!
	Ron Rivest


∂23-Oct-79  1215	MLB@MIT-AI
From: MLB@MIT-AI
Date: 10/23/79 14:56:44

MLB@MIT-AI 10/23/79 14:56:44
To: (BUG lisp) at MIT-MC
YES!  I would like to see the handliing of CR changed.  I get screwed
by the current scheme fairly regularly.


∂24-Oct-79  1753	DKM@MIT-AI
From: DKM@MIT-AI
Date: 10/24/79 20:50:10

DKM@MIT-AI 10/24/79 20:50:10
To: (BUG LISP) at MIT-AI
Changing the meaning of CR is surely a winning idea, for several reasons:

1) People read a CR as being an end-of-symbol.  For example, when you see a
FOO
BAR
   you surely think of this as being two separate symbols, not one.

2) Novice LISP hackers expect a CR to terminate an atom.  I know, having made
   this mistake myself -- I want to find the value of FOO, so I type FOO<CR>
   and soon begin to wonder about ITS's response time.  Another place is in
   typing in a long list of atoms: I type a CR at the end of a line and start
   the next line; LISP ignores the CR, fouling things unnecessarily.

3) CR already has a meaning similar to terminate-symbol: It terminates a ; comment.

Are there any reasons not to change CR?
						DKM


∂24-Oct-79  2229	GSB@MIT-ML
From: GSB@MIT-ML
Date: 10/25/79 01:27:49

GSB@MIT-ML 10/25/79 01:27:49
To: (BUG COMPLR) at MIT-ML
The function DECDEF-DEFINE-ROUTINE-OR-MACRO in ML:LSB;DECDEF LOSE loses
grossly.  It hits the (only) "(break barf)", near the end;
apparently the variable MINARGS does not equal MAXARGS - i gather this
because what gets returned where MINARGS is returned is a very strange
number, coincidentally the instruction "call 2,.function nreconc".
My guess is pdl number lossage.  This worked as of version 365 (october
4), and this function hasn't been changed.  (DECDEF LOSE is version 366.)
  In particular, the following sequence of instructions (near the
front of the function) is suspect:
(MOVE 7. @ -10. P) 
(ADD 7. 0. 1.) 
(PUSH FXP 7.) 
(MOVEI 1. 0. FXP) 
(SUB FXP (% 0. 0. 1. 1.)) 
G0031 
(MOVEM 1. -10. P) 

   The lap is in GSB1;DECDEF LAP.


∂25-Oct-79  0429	JONL at MIT-MC (Jon L White) 	CR convention change
Date: 25 OCT 1979 0727-EDT
From: JONL at MIT-MC (Jon L White)
Subject: CR convention change
To: (BUG LISP) at MIT-MC

Some mail that didn't get forwarded
  Date: 22 Oct 1979 1156-PDT
  From: Dick Gabriel <RPG at SU-AI>
  Subject: Ok  
  What the hell is the new CR change? I assumed, until today, that
  this was only to affect vertical-bar macros. Now it looks like
  it is to be valid in all atoms? If the latter, we object and
  don't want the new code, if the former, sure.




∂25-Oct-79  0753	JONL@MIT-ML 	LSB;DECDEF LOSE  
From: JONL@MIT-ML
Date: 10/25/79 10:50:54
Subject: LSB;DECDEF LOSE

JONL@MIT-ML 10/25/79 10:50:54 Re: LSB;DECDEF LOSE
To: GSB at MIT-ML
CC: (BUG COMPLR) at MIT-ML
Yes, I broke comlr fiddling around with the pdlnumbering stuff,
but just dumped out a good version again.


∂25-Oct-79  1541	GSB@MIT-ML 	how about... 
From: GSB@MIT-ML
Date: 10/25/79 17:43:45
Subject: how about...

GSB@MIT-ML 10/25/79 17:43:45 Re: how about...
To: (BUG LISP) at MIT-ML
.entry untyi subr 003
	movei ar1,(b)
$untyi:	jsp tt,xfosp
	  jrst barf
	  jfcl
	jsp t,fxnv1
	movei a,(tt)
	pushj p,untyi+2
	movei a,.atom T
	popj p,

barf:	exch a,ar1
	wta [NOT FILE OR SFA - UNTYI!]
	exch a,ar1
	jrst $untyi


∂25-Oct-79  2011	Robert W. Kerns <RWK at MIT-MC> 	CR convention change  
Date: 25 October 1979 20:08-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  CR convention change
To: RPG at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 25 October 1979 07:27-EDT
    From: Jon L White <JONL at MIT-MC>
    To:   BUG-LISP
    Re:   CR convention change

    Some mail that didn't get forwarded
      Date: 22 Oct 1979 1156-PDT
      From: Dick Gabriel <RPG at SU-AI>
      Subject: Ok  
      What the hell is the new CR change? I assumed, until today, that
      this was only to affect vertical-bar macros. Now it looks like
      it is to be valid in all atoms? If the latter, we object and
      don't want the new code, if the former, sure.
Would you elaborate?  What are your objections?  How strongly do you
hold them?  How do you feel about the change being only inside vertical
bars?  (I think the change is as important outside as inside, but am willing
to at least consider the idea that they should be considered separately).
If the rest of the world did this, are there different conditions at SAIL
(political, operating-system, editing, or whatever) that make it necessary
to be different?  If it were made SAIL-only for outside, and everybody kept
CR's in vertical bars, I can't see any real problem with transportability,
so my main objection to SAIL doing whatever they want wouldn't hold in that
case.

Care to fill us in on the rest of your opinion on this issue?

∂25-Oct-79  2011	RWK at MIT-MC (Robert W. Kerns)    
Date: 25 OCT 1979 2125-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: RZ at MIT-MC

Why isn't there an ASH function?

∂25-Oct-79  2011	Robert W. Kerns <RWK at MIT-MC> 	CR in LISP  
Date: 25 October 1979 22:49-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  CR in LISP
To: RBRN at MIT-AI
cc: BUG-LISP at MIT-MC

    Date: 10/22/79 11:33:26
    From: RBRN at MIT-AI
    To:   (BUG LISP) at MIT-AI, rwk
    Re:   CR in LISP

    Although there probably are not many programs that depend on CR being ignored, there are
    (or at least historically were) several programs that groveled over LISP code,
    and introduced CRs where none were before. For this
    reason the syntax of CR should be left alone.
    	Besides, what would be the purpose of such a change? 
    	Anyway, for your own use you could probably just modify the syntax via your
    own LISP init file.

What programs are these?  Are there any still in use?  If you mean GRIND,
it hasn't done that in many years.  I can't think of any reason why a
reasonable program would introduce CR's in the middle of an atom.  The purpose
of the change is to make things more compatible with the rest of the world.
Currently, ITS MACLISP is incompatible with Multics MacLisp even.  The LISP
Machine already does things this way; wouldn't you like your code to be
compatible between it and ITS?

Obviously, this has nothing to do with my own use.  It would be a mistake
for me to set it this way in my init file, since then I would be incompatible
with everybody else.  I think most people do want it changed.

∂25-Oct-79  2011	Robert W. Kerns <RWK at MIT-MC>    
Date: 25 October 1979 22:51-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: BUG-LISP at MIT-MC
cc: EAK at MIT-MC

    Date: 22 October 1979 10:51-EDT
    From: Earl A. Killian <EAK at MIT-MC>
    To:   RWK
    Re:   Effect of CR in symbols

    I was sort of grossed out that FOO<cr>BAR read in as FOOBAR
    instead of FOO<sp>BAR.  I think it is highly non-obvious.  When I
    complained, the reason I got was that PRINT liked to print FOOBAR
    as FOO<cr>BAR to avoid overflowing the linel.  Seems poor to me.
That indeed was part of the original reason.  The decision dates from before
ITS handled breaking of lines, I think.

∂25-Oct-79  2011	Robert W. Kerns <RWK at MIT-MC> 	CR in symbols and strings  
Date: 25 October 1979 22:56-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  CR in symbols and strings
To: RLB at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 22 October 1979 08:20-EDT
    From: Richard L. Bryan <RLB at MIT-MC>
    To:   BUG-LISP
    Re:   CR in symbols and strings

    I've been waiting for that for years.  However, there's always the issue of
    compatibility with files written by older MacLISPs.  What happens if a
    symbol with FLATSIZE > linel is written?  MacLISP currently offers no 
    line continuation character sequence, and either one would be needed, or
    else we'd have to decide that it would be ok to write past linel.
My answer is that we should decide that it's ok to write past linel if we
don't have a choice.

∂25-Oct-79  2025	Robert W. Kerns <RWK at MIT-MC> 	CR
Date: 25 October 1979 23:21-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  CR
To: GJC at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 21 October 1979 19:26-EDT
    From: George J. Carrette <GJC at MIT-MC>
    To:   BUG-LISP
    Re:   CR

    Uhm, the only changes it would make in my code is it would add extra CR's to
    stuff inside |...|  The example is this:

    (DOCUMENT-MACRO DOC1 '|
    text......./
    kdkdkjfjdk/
    |

    )
    That is, I use the first hidden CR to make it easier to line up the document
    text. But slashing all the CR's I want is also a pain. So I'd rather
    have the extra CR ...
What's wrong with:
    (DOCUMENT-MACRO DOC1 '
|text.......
kdkdkjfjdk
|
    )

Which is less extra characters on each line?

∂25-Oct-79  2030	Robert W. Kerns <RWK at MIT-MC> 	Effect of CR in symbols    
Date: 25 October 1979 23:26-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  Effect of CR in symbols
To: SJOBRG at MIT-AI
cc: BUG-LISP at MIT-MC

    Date: 10/21/79 15:49:17
    From: SJOBRG at MIT-AI
    To:   (BUG LISP) at MIT-AI
    Re:   Effect of CR in symbols

    I think <cr> should be a break character identical to space.
    Does the proposed change mean just that, or something else?
It does NOT mean it is identical to space, which I don't think you mean
either.  Consider
|FOO
BAR|
I don't think you mean to claim this should be the same as
|FOO BAR|.

If you mean "It should break symbols when unquoted, just like SPACE",
then yes.

∂25-Oct-79  2038	Dick Gabriel <RPG at SU-AI> 	CR convention change 
Date: 25 Oct 1979 2030-PDT
From: Dick Gabriel <RPG at SU-AI>
To:   bug-lisp at MIT-AI    

 ∂25-Oct-79  2011	Robert W. Kerns <RWK at MIT-MC> 	CR convention change  
Date: 25 October 1979 20:08-EDT
From: Robert W. Kerns <RWK at MIT-MC>
Subject:  CR convention change
To: RPG at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 25 October 1979 07:27-EDT
    From: Jon L White <JONL at MIT-MC>
    To:   BUG-LISP
    Re:   CR convention change

    Some mail that didn't get forwarded
      Date: 22 Oct 1979 1156-PDT
      From: Dick Gabriel <RPG at SU-AI>
      Subject: Ok  
      What the hell is the new CR change? I assumed, until today, that
      this was only to affect vertical-bar macros. Now it looks like
      it is to be valid in all atoms? If the latter, we object and
      don't want the new code, if the former, sure.
Would you elaborate?  What are your objections?  How strongly do you
hold them?  How do you feel about the change being only inside vertical
bars?  (I think the change is as important outside as inside, but am willing
to at least consider the idea that they should be considered separately).
If the rest of the world did this, are there different conditions at SAIL
(political, operating-system, editing, or whatever) that make it necessary
to be different?  If it were made SAIL-only for outside, and everybody kept
CR's in vertical bars, I can't see any real problem with transportability,
so my main objection to SAIL doing whatever they want wouldn't hold in that
case.

Care to fill us in on the rest of your opinion on this issue?

It sounds as though you are arguing for a convention we have had for
years, namely, that foo<cr>bar => foo<sp>bar not foobar.  I forgot that
ITS did thatwrong. I hope that inside vertical bars it will be consistent
after the change.
			-rpg-




∂25-Oct-79  2132	RWK at MIT-MC (Robert W. Kerns)    
Date: 26 OCT 1979 0029-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: rpg at SU-AI
CC: (BUG LISP) at MIT-MC

Great.  Then you also think it's OK for
|foo
bar|
to be the same as
|foo/
bar| ?  If so, then we agree?

∂26-Oct-79  2216	GJC at MIT-MC (George J. Carrette) 
Date: 27 OCT 1979 0114-EDT
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

In L;ARITH > I noticed a few SQRT algorithms, some of
which were titled "another old sqrt algorithm".
Q: Which one do you get when you do (SQRT ...) ?

∂26-Oct-79  2315	RWK at MIT-MC (Robert W. Kerns)    
Date: 27 OCT 1979 0211-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, NIL at MIT-MC

Would it cause any problems or be too hard for the number scanner to ignore
commas?  JPG and probably others would like to be able to group digits of
their numbers...  Also, comma-return could be ignored (why not, it's quite
unambiguous).

∂26-Oct-79  2330	Robert W. Kerns <RWK at MIT-MC>    
Date: 27 October 1979 02:23-EDT
From: Robert W. Kerns <RWK at MIT-MC>
To: GJC at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 27 October 1979 01:14-EDT
    From: George J. Carrette <GJC at MIT-MC>
    To:   BUG-LISP

    In L;ARITH > I noticed a few SQRT algorithms, some of
    which were titled "another old sqrt algorithm".
    Q: Which one do you get when you do (SQRT ...) ?
The sequence COMMENT | ...| is a comment, so the algorithms which have that
around them are commented out.  The current one is the last one found.
The one that GLS says he doesn't understand (in the comments preceeding), by
Kahil. 

∂27-Oct-79  1014	JONL at MIT-MC (Jon L White) 	Mail at Sail ? 
Date: 27 OCT 1979 1311-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Mail at Sail ?
To: rpg at SU-AI, rod at SU-AI
CC: (BUG lisp) at SU-AI

As per ROD's instructions, I'm removing these names
off the NIL mailing list tempporarily, until Sail 
gets settled down again.  Also, I've removed them off
the BUG-LISP list at MC.  If you can login to MC
durining the move, you will find this mail posted
in the files  NIL;NIL MAIL  and LISP;BUG MAIL

∂27-Oct-79  1823	GSB@MIT-ML 	scrod again  
From: GSB@MIT-ML
Date: 10/27/79 21:20:50
Subject: scrod again

GSB@MIT-ML 10/27/79 21:20:50 Re: scrod again
To: (BUG COMPLR) at MIT-ML
In ML:GSB;LODBYT LOSE (version 23), in the macro definition of
MASK-FIELD, the (boole 1 frob mask) returns a pdl number, then
exits, invalidating the pdl number.


∂26-Nov-79  0442	GSB@MIT-ML
From: GSB@MIT-ML
Date: 11/21/79 14:00:35

GSB@MIT-ML 11/21/79 14:00:35
To: (BUG COMPLR) at MIT-ML
(COMMENT ****  (EQ BASE (QUOTE ROMAN)) EQ of a number - EQUAL assumed in function %SMARTOBJ-PRINT-NUMBER)
Please take this EQUAL and stick it into the pdl number allocater.


∂26-Nov-79  1903	H at MIT-AI (Jack Holloway)   
Date: 26 NOV 1979 2201-EST
From: H at MIT-AI (Jack Holloway)
To: (BUG QC) at MIT-AI

The compiler's error message for directory full
is "randomness in complr-tople...".